/*! \mainpage
	\section Purpose
		This application will provide the full control logic for the trains
*/

#include <unistd.h>
#include <cstdlib>
#include <ctime>
#include <iostream>
#include <fstream>
#include <vector>


using namespace std;

// Custom includes

#include "objects/rfid_tag.hpp"
#include "objects/block.hpp"
#include "objects/schedule.hpp"
#include "functions/init.hpp"
#include "functions/logging.hpp"

#define _VERSION_ "0.0.1"

int main(int argc, char* argv[]) 
{
	
	// Variables 	
	fstream router; //! This file is the base node of the network!
	int tmp;
	// Error Checking
	
	// Input Arguments
	while ((tmp = getopt(argc, argv, "P:h")) != -1) {
		switch (tmp) {
			case 'P':
				cout << "Init Serial Port..." << endl;				
				cout << "Check!" << endl;
				break;
			case 'h':
				cout << "-P <serial port>" << endl;
				break;
			case '?':
			default:
				cout << "help menu TBD" << endl; 
				exit(-1);
				break;
		}

	}
	
	// Init sequence
	init_logging();
	
	log("Booted Version " << _VERSION_);
	
	// Main Loop
	
	return 0;
}




/*!
	\page commevents Schedule Example
	
	\section example
	The schedualer object is first called to process its own list. This will involve clean up, upates, and calling any due events. Here we assume that a train (BOB) needs to be routed to a waypoint (Water Station).
		- The schedualer object decides to route train Bob to the Water station. 
			- "TBOB R SWATER"
		- The schedule object calls the train object to see if it is busy.
			- If it is busy, log the error and delay the event.
			- This error flag needs to be created...
		- The train must now attempt to route itself to the Water station. 
		- Call the global RFID map to route to the destination.
			- If the route cannot be made for any reason, log error
			and cancel the event. 
			- This error flag needs to be created...
		- If the route was sucessful, save this to Bobs routing pointer
		- Send XBee frame to Bob to tell him to start his route
		
		The XBee object is now called. This object will handle the rest of the route for bob, and his event should no longer require interaction from the scheduale object. 
		- XBee object clears out any incomming data first. 
		- Incomming requests are processed.
		- Outgoing data (to Bob) is processed and sent.
		- The next interation through the loop, Bob should now request his next order.
		- The Bob object is called, and its next order is processed
			- If any switches must be operated, their commands are sent
			- If any switches were operated, have Bob wait until their are comfirmed switched. 
		- Bob is issued a command that should bring him across his next RFID tag. 
		- Bob will respond when he reaches this tag for his next command. 
		- The above steps will repeat until Bob has reached the end of his orders list. 
		- Bob is then given the status tag that he is avaliable for orders. 
		
		The final step of this loop should record the time stamp from when the XBee buffer was last read. This will then be used to calculate how long to wait between the schedual object and the xbee object. The idea beaing that as much idle time as possiable should be kept. Logging should keep track of idle %. 
	\section Dependencies
	
	From the above example, the following dependencies can be extracted. 
	
	- Schedule
		- xbee.hpp
			- Must be able to add events. 
		- vehicle.hpp
			- Must be able to request a train route itself.
	- XBee
		- vehicle.hpp
			- Must be able to process any routes
	- Vehicles
		- rfid_tag.hpp
			- Must be able to route though the RFID map

*/